Office Open XML est une spécification technique créée par
Microsoft, destinée à répondre à la demande d'
Interopérabilité dans les environnements de
Bureautique. Elle est utilisée par Microsoft Office 2007, en remplacement des précédents formats Microsoft (
doc,
xls, ppt...).
Après avoir fait valider son format comme un standard de l'ECMA, Microsoft a confié à cet organisme le soin de le proposer à la normalisation ISO. Après un premier vote négatif en Septembre 2007, la normalisation est votée le 29 mars 2008, ce qui ne manque pas de provoquer une certaine polémique, nourrie par la rivalité entre les partisans des normes OpenDocument (ISO 26300), jugée plus ouverte, et Office Open XML.
Contexte et historique
Microsoft Office (suite bureautique réunissant entre autres
Microsoft Word,
Excel et
Powerpoint) est devenu au cours des
Années 1990 le logiciel de bureautique le plus utilisé, au point de tenir une situation de quasi-monopole. Parallèlement, les formats de fichier utilisés par la suite (.doc, .xls, .ppt, etc.), binaires, propriétaires et non documentés sont devenus des standards
de facto. Cet état de fait nourrissait la situation de monopole de la suite Microsoft Office : sans documentation de ces formats devenus standards, les logiciels concurrents de
Microsoft Office ne pouvaient espérer en égaler les performances.
L'adoption par l'ISO du format de fichier bureautique ouvert ODF en 2006, et sa disponibilité sur de nombreuses plate-formes logicielles, a brutalement changé la donne en matière de format de bureautique. Une norme était proposée, là où n'existait qu'un standard de facto, non documenté et lié à un éditeur privé.
Face à l'exigence des utilisateurs de bénéficier d'un format de données XML, standardisé et documenté, Microsoft créa son propre format, concurrent de l'ODF : l'Office Open XML. Il le fit reconnaître comme standard documenté par une organisation de standardisation informatique, l'ECMA, en décembre 2006, dans le but de le faire valider par l'ISO.
S'ouvrit alors une guerre des formats, aussi bien sur le plan technique que politique, dont les enjeux stratégiques sont énormes: si Microsoft devait perdre l'avantage d'être propriétaire du format standard de bureautique, alors sa suite Microsoft Office se trouverait en concurrence directe et égale face à ses concurrents (OpenOffice.org, Star Office, etc.).
Norme ECMA-376 : Office Open XML File Format
Office Open XML (également abrégé
OOXML ou plus communément
Open XML) est la désignation d'usage d'un standard de l'ECMA dont l'appellation officielle est «
ECMA-376 : Office Open XML File Format » définissant un format de données pour les documents d'applications bureautiques :
traitements de texte,
tableurs, présentations, diagrammes, dessins et formules mathématiques. Ce format est à l'instar du format ISO
OpenDocument structuré en XML et Zip.
Originellement introduit par Microsoft, puis revu dans le cadre de sa standardisation par l'ECMA, ce format est structuré selon l'Open Packaging Convention qui définit un système de stockage des données flexible en utilisant une navigation logique à base de relations. La description sémantique des données se fait par l'ensemble des schémas XML normalisés.
Pour des raisons d'interopérabilité avec les anciens formats binaires d'Office, la partie réservée à la compatibilité de la spécification - partie entièrement optionnelle - mentionne néanmoins des éléments non-normalisés qui sont la propriété intellectuelle de Microsoft comme le WMF, la sauvegarde des données concernant le format d'impression et certains détails d'anciens logiciels édité par Microsoft. Dans ce cadre, Microsoft a publié un Covenant Not to Sue (ou CNS) s'engageant pour le futur à ne pas gêner les acteurs à utiliser le format, même si cela empiète sur la propriété intellectuelle de la firme. Une étude du cabinet d'expertise juridique anglais Baker & McKenzie, effectuée aux frais de Microsoft, décrit la validité et la portée juridique du contenu de ces documents en y engageant sa réputation. Dans la pratique, seule une jurisprudence pourrait donner une lecture certaine de ce document.
Ce format est présenté par l'auteur comme destiné à être utilisé par tous pour communiquer et aussi pour archiver les documents administratifs, culturels ou scientifiques et donc préserver une grande partie de notre patrimoine intellectuel ou historique, des enjeux techniques, économiques et de société.
Norme ISO DIS 29500
Historique des votes ISO
Les pays membres de l'ISO ont discuté et revu techniquement le standard ECMA-376 dans le but de s'assurer de la cohérence et de l'intérêt du contenu de la spécification.
Le 19 juillet 2007 le processus de normalisation ISO de OpenXML a subi un revers, le comité technique V1 ayant refusé l'état "approuvé avec commentaires" (qui signifie accepté), et aussi l'état "désapprouvé avec commentaires" (qui implique une demande de modification pour un probable accord ultérieur). Le comité technique en question était pourtant passé de 7 participants au 1er janvier à 26 participants, les nouveaux entrants ayant majoritairement votés en faveur de l'adoption.
Le 10 août 2007, le format Office Open XML fait l'objet d'un premier rejet à l'ISO : l'abstention de l'IEEE provoque la non-présentation du format à l'ISO.
Le 4 septembre 2007, le vote du comité ISO, planifié pour la potentielle nomination de ce standard au statut de normes ISO, est négatif (le vote ne recueille que 53% de votes positifs, alors qu'il est nécessaire de réunir plus de 66% de votes positifs et moins de 25% de votes négatifs). Le représentant de la France à l'ISO (l'association française de normalisation Afnor), qui possède une voix lors de ce vote, choisit de voter "non avec commentaires".
Un projet de norme contestée
La possibilité de reconnaitre OpenXML comme norme internationale est/a été contestée lors de la procédure de normalisation ISO 29500, suite à une série d'éléments tant juridiques que techniques qui pourraient rendre malaisée l'implémentation d'OpenXML. Suite à ces contestations, l'ECMA a formulé un document de réponse, destiné aux instances internationales, justifiant des choix techniques.
En plus des réponses apportées par l'ECMA, Microsoft a répondu à certains des points ambigus soulevés par les états dans un communiqué officiel.
Le statut de norme pour Office Open XML est jugé tendancieux par de nombreuses associations promouvant le logiciel Libre,.
Des entreprises comme IBM avancent que la norme est trop liée aux plate-formes du passé et désirent rompre avec cet état de fait.
L'ODF Alliance, promotrice de l'OpenDocument, propose une feuille de faits qui dénonce la difficulté à transposer Office Open XML à d'autres suites bureautiques, la taille du document de la spécification, la redondance avec les standards actuels.
Conflits avec les normes existantes
Il existe déjà une norme
ISO 26300 pour décrire les documents de
Bureautique. La proposition de normalisation d'OpenXML contredirait les normes ISO 8601 (représentation des dates et des périodes), ISO 639 (codes pour la représentation des noms et des langues) ou ISO/IEC 10118-3 (fonctions de hachage en cryptographie).
Mise en cause du caractère libre
Microsoft a distribué, en plus de l'existant
Open Specification Promise un document promettant de ne pas poursuivre les auteurs de l'utilisation de Office Open XML dans un autre logiciel que ceux de Microsoft. Cette promesse de non-poursuite elle-même laisse certains flous, notamment :
- s'appliquant à la norme ECMA en l'état, s'appliquera-t-elle à une éventuelle version finale de l'ISO ?
- s'applique-t-elle, aux États-Unis (pas de brevets logiciels en Europe), à tous les brevets nécessaires à la mise en oeuvre de la norme ?
- s'appliquera-t-elle également aux extensions du format OOXML ?
La licence d'utilisation de OpenXML est incompatible avec les programmes sous la licence GPL,.
Certaines associations d'industrie ont même écrit à l'ECMA pour faire valoir que OpenXML était "non conforme aux conditions fondamentales de l'ouverture" (à l'époque).
Mise en cause du caractère documenté
La possibilité et/ou facilité de transposition du format à d'autres suites bureautiques ou bibliothèques indépendantes de l'auteur original, a été remis en cause. Pourtant de nombreux produits implémentent le standard ECMA, en partenariat avec Microsoft (la version Novell de OpenOffice.org, NeoOffice, Corel WordPerfect, MindManager Mindmapping, Altova XMLSpy) ou non (
Liste vide).
Plusieurs bibliothèques permettent aux développeurs/éditeurs de logiciels de créer des applications.
Mise en cause du mode Fast Track
L'
ECMA a demandé l'examen de la proposition de norme OpenXML par l'ISO selon le mode rapide dit « fast track », mode qui demande que les éventuelles contestations soient formulées dans le délai de 1 mois. Ce mode rapide est contesté par plusieurs organisations, en particulier au regard de la taille excessive de la proposition: plus de 6000 pages, à comparer avec la taille habituelle (en moyenne 11 pages) des normes de l'ISO.
Malgré une majorité de votant contre l'adoption de cette procédure (14 négatifs, 5 neutres/mitigés et 1 pour), la procédure fut néanmoins acceptée par le bureau du TC1 en fonction des prérogatives dévolues au président.
Erreur technique remettant en cause le caractère de norme
Il est fait mention dans le document proposé de logiciels tel que « Word95 », or une norme ne peut citer de marque (élément alignAsWord95, autoSpaceLikeWord95, useWord97LineBreakRules).
Office Open XML devient une norme ISO le 29 mars 2008
Le
29 mars 2008, le vote d'adoption d'Office Open XML comme norme internationale DIS 29500 est positif, ce qui provoque une certaine polémique. L'Afnor, le représentant français, qui avait voté contre lors du premier vote, a décidé au dernier moment de s'abstenir. Alors que 80% du
comité norvégien voulait garder le "non" du permier vote, la Norvège se déclare finalement favorable à la normalisation de l'Office Open XML. La commission européenne décide d'ouvrir une enquête sur les conditions de ce vote.
Contenu technique de la norme
Le format Office Open XML utilise une structure respectant l'Open Packaging Convention et définissant de façon simple et logique la structure interne de tous les documents Office Open XML. Selon cette convention, les documents sont des archives ZIP dont les différents éléments le constituant, appelés
parties, sont reliées entre elles par des
relations logiques. L'utilisation du ZIP permet outre de compresser les documents, de pouvoir stocker les données de façon totalement indépendante dans une architecture segmentée.
Cette architecture permet d'ailleurs de protéger les documents Office Open XML plus efficacement face à la corruption des données (si un élément est endommagé, les autres n'en seront pas affectés).
Le paquet
La notion de
paquet définit l'archive ZIP en elle-même, c'est à dire le conteneur des données d'un document Office Open XML.
Une partie
Une partie est un élément de l'archive ZIP, c'est à dire un fichier compressé et intégré dans la structure du ZIP. On distingue plusieurs types de parties : les parties de contenu et les parties de relations.
Les parties de contenu contiennent les données même du document, c'est à dire les informations qui définissent les données et la sémantique d'un document Office Open XML. Ces parties peuvent contenir du XML (par exemple le contenu d'un document de traitement de texte : paragraphes, runs, graphiques, ...) ou des données binaires (par exemple des images GIF, JPEG, etc ou des objets OLE).
Les parties de relations contiennent une structure XML définit dans les schémas de référence du standard ECMA-376.
Une partie spécifique et unique dans le paquet est celle des types de contenu décrite plus en détail dans une prochaine partie.
Les relations et les parties de relations
Les relations sont définies dans les parties de relations et spécifient les liens entre le paquet ou une partie source et une partie cible.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId3" Type="http://schemas.../metadata/core-properties" Target="docProps/core.xml" />
<Relationship Id="rId2" Type="http://schemas.../metadata/thumbnail" Target="docProps/thumbnail.jpeg" />
<Relationship Id="rId1" Type="http://schemas.../officeDocument" Target="word/document.xml" />
<Relationship Id="rId4" Type="http://schemas.../extended-properties" Target="docProps/app.xml" />
</Relationships>
Une relation possède un type de relation spécifiant la nature de la partie pointée, et l'URI relative à la partie ciblée.
Les parties de relations possèdent un nom, représenté par une URI, qui doit respecter une convention de nommage particulière. Cette syntaxe stipulée dans le standard est le suivant : <chemin hiérarchique>/_rels/<nom de la partie source>.rels.
Exemples :
- la partie de relation du paquet n'a pas de partie source, puisque celle-ci est située à la racine même du document (et est obligatoire), sa syntaxe est unique : /_rels/.rels
- la partie de relations de la partie principale de contenu d'un document WordprocessingML possède l'URI suivante : '/word/document.xml', par conséquent la partie de relation associée (qui permettra par exemple, au contenu de cibler une image insérée dans le document) devra posséder l'URI suivante : /word/_rels/document.xml.rels
Partie des types de contenu
Cette partie obligatoire porte un unique nom :
.xmlCe nom n'est pas compatible avec la syntaxe d'une URI: cela est un choix technique. Voici un exemple de contenu de la partie de types de contenu :
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
<Override PartName="/ppt/slides/slide5.xml" ContentType="application/vnd.openxmlformats-officedocument.presentationml.slide+xml" />
<Default Extension="png" ContentType="image/png" />
<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml" />
<Default Extension="xml" ContentType="application/xml" />
...
</Types>
Cette définition de type définit deux types d'extension, celle par défaut qui spécifie que tous les éléments possédant l'extension stipulée sont du type défini, et celle qui surcharge l'extension définie par défaut en stipulant un type spécifique pour une partie spécifique.
Tous les types de contenu doivent être compatibles avec la RFC 2616 §3.7 (en tenant compte des règles du modèle d'empaquetage, le support des paramètres de type de contenu est proscrit).
Parties de signature numérique
L'objectif des parties de signature est d'assurer la sécurité des documents afin d'en garantir au moins l'intégrité et/où l'accès grâce à des certificats
X.509.
Ces parties contiennent plusieurs informations qui sont détaillées dans une partie ultérieure.
Cette section est vide, pas assez détaillée ou incomplète. Votre aide est la bienvenue !Voir aussi
Liens internes
Liens externes
Notes et références